iT邦幫忙

2022 iThome 鐵人賽

DAY 1
4
Modern Web

致 JavaScript 開發者的 Functional Programming 新手指南系列 第 1

Day 1: 致 JavaScript 開發者的 Functional Programming 指南(修正版)

  • 分享至 

  • xImage
  •  

嗨,大家好!歡迎來到「致 JavaScript 開發者的 Functional Programming 指南」!

在切入到正題前,首先想要跟大家說說自己與 JavaScript 的小故事。

首先,在成為開發者以前,我沒有相關電腦科學的背景,大部分都是透過網路的課程或是官方文件來進行學習。

最一開始我是使用 Vue 作為主要的前端開發框架,學習的方式主要是閱讀 Vue 官方文件,由於 Vue 是一個非常好上手的模板框架,在一開始使用時非常方便,大部分的時候都可以透過官方文件找到適合的語法及工具。

然而隨著自己進到職場,開始要與越來越多人協作,開發專案的規模也越來越大時,自己面臨到所謂「架構」的問題。

當時的我只知道優良的程式碼架構可以解決很多的問題,但卻不知道該從何下手,遇到最具體的問題大概是封裝專案的共用元件。

這些共用元件除了自己以外,也許會有其他的夥伴拿來使用,甚至自己可能在未來也會重複使用到,此時自己遇到了一個非常大的挑戰:「到底元件要怎麼封裝會比較好呢?

由於當時團隊中並沒有導入明確的協作方式,並且大家對於模組的設計都有自己的一套想法,對於還是前端新手、對技術掌握度不高的我感到非常頭痛。

不曉得大家有沒有類似的經驗?在剛開始撰寫程式碼的時候,如果沒有明確的範例指引,或是某個具體的守則,初階的軟體工程師很容易就在撰寫程式碼的過程失焦,更別提當自己在一個專案中看到多種不同撰寫風格時,管理起來能有多混亂了。

「到底怎麼樣封裝才是好元件?」

這個問題在我下班後依然在腦裡揮之不去,時不時就會透過一些關鍵字查找元件封裝的方式,但依然沒有找到踏實答案的感覺。

後來因緣際會開始使用 React 框架進行開發,這一次我同樣是使用 React 所提供的官方文件來學習,且發現到這兩種框架在文件撰寫上風格大不同。

Vue 官方文件偏向提供「工具的使用方式」,但至於怎麼用比較好、什麼情境下適合使用,在文件上沒有提及太多,然而 React 的學習文件中,都會建議開發者使用怎麼樣的「風格」最適合 React 的開發模式。

此時「Functional Programming 」這個設計典範開始充斥我的開發日常,我發現有了設計典範的指引,我開始能自己思考什麼是「好的程式碼」,也慢慢開始了自己的優化程式碼之路。

如果你跟我一樣也正想優化自己的 JavaScript 程式碼,但不知道要從何下手,也許可以跟我一起投入 Functional Programming 的懷抱!

希望可以透過本系列文章向大家分享 Functional Programming 是多麽美妙的工具,也讓更多使用 JavaScript 的開發者們對於 Functional Programming 有更具體、脈絡化的認識。

從 JavaScript 核心到 Functional Programming

在一些技術書籍中,會將 FP 譯作「函式程式設計」或是「功能性程式設計」,為了讓大家可以更直覺的理解這個設計典範,當提及 Functional Programming 時,我們會使用 FP 這個簡寫來取代中譯。

在現代網頁開發的時代,網頁的開發工具非常齊全、也非常多,撇開一些建立在 JavaScrtip 之上的主流框架,更多時候我們還是使用原生的 JavaScript、HTML 及 CSS 進行網頁開發。

我們不需要透過框架,就可以使用 FP 的設計概念進行開發,如果不曉得什麼是設計典範也沒關係,我們後續會針對這兩者的概念進行夠深入的介紹。

在這次的系列內容中,我主要會使用原生的 JavaScript 進行討論,偶爾會使用一些函式庫搭配講解概念,內容大致上會囊括以下有關 FP 的核心概念:

  • Immutable Data
  • Mutation
  • 純函式(Pure Function)
  • 柯里化(Curry)
  • 高階函式(High Order Function)
  • 複合函式(Function Composition)

上述這些概念,會將大部分會與 JavaScript 的核心概念或是在瀏覽器上運作的原理有關,所以在系列文章中,也會穿插以下概念,或是說以下的這些概念不理解的話,會很難深刻了解我們實質上要透過 FP 來解決 JavaScript 中的什麼問題,這些概念包含:

  • 型別
  • 函式
  • 陳述式與表達式
  • 解構賦值
  • 閉包
  • 瀏覽器運作原理
  • Call stack

透過以上概念的結合,可以更了解為什麼 JavaScript 可以透過採用 FP 解決一些既有問題,以及為什麼我們討論的角度會是以 JavaScript 作為切入點,而不是單純了解 FP 這個設計典範而已。

由於本系列文章是以探討 FP 與如何在 JavaScript 這門語言中實踐 FP ,對於 JavaScript 的核心理論並不會全面囊括,只會大致講到講到與實作 FP 有相關的部分,也不會著重在如何使用 JavaScript 這門語言。

基於以上原因,這篇文章會適合以下類型的人閱讀:

  1. 對於 JavaScript 有一定的掌握程度 、想了解 FP 的開發者
  2. 有使用過 Angular、React 或是 Vue 框架的開發者
  3. 想更好提升元件、函式複用性,降低臭蟲發生機會的開發者

如果目前你對於網頁的實作、開發不熟,甚至不太知道什麼是 AJAX、Web API、JavaScript 等網頁開發的必備技術,那這系列的內容可能會相對生硬,因為我們會需要理解許多生硬的名詞及實務上的技巧。

在這個系列文章中,會穿插程式碼範例、自己針對 FP 額外的思考與實務上的開發應用。

在內文的範例中,會有一些不難但是會需要思考的程式碼,可以的話可以搭配一些線上程式碼編輯器服務:Codepen、JSbin、Babel 等服務,在思考的過程中,搭配實作, 有助於更快了解 JavaScript 及如何在我們的 JavaScript 中導入 FP 這個設計典範。

最後,希望可以用平易近人的角度來帶大家使用 FP,那麼就讓我們開始吧!

為了大家可以更快的找到自己需要的「重點」,這裡提供本系列文章的目錄:


下一篇
Day 2 :初探設計典範(1):FP 的崛起、沒落、東山再起(修正版)
系列文
致 JavaScript 開發者的 Functional Programming 新手指南30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

1
obarisk
iT邦研究生 1 級 ‧ 2022-09-12 21:26:34

functional programming 是一種典範(paragiam)。

設計模式(design pattern) 在不同的典範之下都可以實作。
當然不是每一種設計模式都可以在各種典範之下都可以做出來。


fp 是一種開發典範,就像 oop 一樣。
他可以在不同的程式語言上體現(前提是 function 是該程式語言的一等公民)。


至於實作元件,實作介面而把實作的細節封裝起來才是最重要的。
介面要越一致越穩定最好。

效能跟實作因為已經被封裝了,使用者不一定需要知道實作。
至於不同作者實作的套件,使用者只要選擇喜歡的介面,以及可以接受的效能即可。

非常感謝大大的提醒 /images/emoticon/emoticon16.gif
自己對設計模式與典範的理解還沒有很深,但內文有多處都有提到「設計模式」,這邊會等有時間把它修正,非常感謝 Q Q

obarisk iT邦研究生 1 級 ‧ 2022-09-13 20:46:29 檢舉

設計模式。design pattern 應該是另一堂課

我要留言

立即登入留言